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Verfahren zur Bearbeitung von CDR-Inf ormationen 



10 Beschreibung 




Die Erfindung betrifft ein Verfahren zur Analyse und 
Bearbeitung, insbesondere Korrektur einer Menge von Call 
15 Detail Records (CDRs) . 

Gebiet der Erfindung: 

Verschiedenste Netzelemente von Mobilf unkbetreibern oder 
anderen Dienstlei stern (Finanzinstitute, Energieunternehmen, 
Internetserviceprovider) erzeugen servicerelevante Daten, so 
20 genannte Call Detail Records (CDRs) , die zum GroJiteil in die 
^^^^Rechnungserstellung einflieBen. Die meisten CDRs liegen in 
^^proprietaren binaren Formaten vbr und werden von so genannten 
Mediation Devices u. a. eingesammelt , aggregiert und auf 
interne oder standardisier.te Datenf ormate zur 
25 Weiterverarbeitung innerhalb einer Abrechnungskette 
abgebildet • 

Die Abrechnungskette, die die Verarbeitung dieser 
servicerelevanten Abrechnungsdaten vornimmt, ist ein hoch 
komplexes, mehrstuf iges Softwaresystem, das meist von 
30 verschiedenen Hard- und Sof twarelief eranten realisiert wurde. 
Durch die Komplexitat und die standig anfallenden 
Anderungswiinsche kornmt es permanent vor, dass ein gewisser 
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Teil der Abrechnungsdaten f ehlerbehaf tet ist und dadurch nicht 
abgerechnet werden kann. Unabhangige Branchenkennzahlen 
sprechen von ca. 2-5% Verlusten. 

■ : Aufgabe der Erfindung: 

^5 Aufgabe der Erfindung ist es, ein Analyse- und/oder 

Korrektursystem bereitzustellen, mit dem es moglich ist, 
abrechnungsrelevante Daten allgemeingiiltig zu analysieren, 
Fehler zu finden, diese zu reparieren und die reparierten 
Daten der Abrechnungskette wieder zuzufiihren. 

• Diese Aufgabe wird durch die Erfindungen mit den Merkmalen der 
unabhangigen Anspriiche gelost. Vorteilhafte Weiterbildungen 
der Erfindungen sind in den Unteranspruchen gekennzeichnet . 

Dies wird im Wesentlichen dadurch erreicht, dass in einer 
Konf igurationsdatei Strukturinf ormationen hinterlegt sind, die 

1.5 die Grammatik der CDRs wiedergeben. Diese Dateien werden 
eingelesen und es wird eine relationale Datenbank auf der 
Grundlage der Grammatik erzeugt. Hierbei ist insbesondere zu 
beachten, dass hierarchische Grammatikkonstrukte, die 
Rekursionen erlauben, durch eine 1:N Verkniipfung dargestellt 

20 werden. Nach dem Erstellen der Datenbank werden die CDRs in 

©die Datenbank eingelesen, um dann mit frei def inierbaren oder 
vorgegebenen SQL-Queries nach Fehlern zu suchen, die ggf . auch 
automatisch korrigiert werden konnen. Nach der Korrektur 
werden die CDRs aus der Datenbank auf der Basis der 
25 Strukturinf ormationen ausgelesen und im ursprunglichen Format 
abgespeichert - 

Das System stellt hierdurch Funktionen zur Analyse und 
Behebung von Fehlern in vom Mediation Device gesammelten oder 
erzeugten CDRs mit abrechnungsrelevanten Daten aus beliebigen 
30 Datenquellen zur Verftigung. Dazu ist es notig, CDRs-diverser 

Formate fur schnelle Suche zwischenzuspeichern, fehlerhafte zu 
erkennen und zu analysieren. Das erf indungsgemafie 
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Korrekturverf ahren ist zur Unterstutzung von Massenupdates 
ausgelegt . 

Fehler in den CDRs haben die Eigenschaft, mehrfach und iiber 
: langere Zeit aufzutreten; deshalb ist eine Wiederholbarkeit 
5 von Analysen und Korrekturmaflnahmen verfiigbar. Das 

erf indungsgemafie System ermoglicht ebenfalls, eine liickenlose 
Riickverf olgung und Wiederverwendung aller gemachten 
Korrekturen, indem protokolliert wird, wer zu welchem 
Zeitpunkt welche Anderung vorgenonunen hat. Dies wird durch das 
10 Anlegen von Kopien erreicht, auf denen alle 

Anderungsoperationen durchgefiihrt werden. Des Weiteren bietet 
das System Revisionssicherheit, d. h. dass zu jedem spateren 
Zeitpunkt mit den gleichen Eingangsdaten die Korrekturen 
erneut durchgefiihrt werden konnen und zu den gleichen 
15 Endergebnissen fiihren. 

Eine weitere Systemeigenschaf t ist die Unterstutzung der 
Benutzer mit Anzeigen und Sortiermoglichkeiten zur optimalen 
Darstellung von Suchergebnissen und von vorgenommenen 
Korrekturen. 

20 So stehen in der bevorzugten Ausf uhrungsf orm folgende 

©Systemfunktionen zur Verfiigung: Eingabef unktionen und 
Zwischenspeicherung von Modif ikationen, dynamische Bestimmung 
der Strukturdef inition der Eingabe-CDRs, Abbildung der 
Strukturdef inition auf die zwischenspeichernde Datenbank, 
25 leistungsf ahige Eingabeschnittstellen in die Datenbank, Laden 
in eine relationale Datenbankinstanz, Import von durch 
Wildcards identif izierten Dateien, Importf ormatierung mittels 
der Strukturdef initionen, Wiederauf setzen bei defekten 
Bereichen, Header- und Trailertest, insbesondere fur das TAP3- 
30 Format, Behandlung von defekten Bereichen in CDR-Dateien nach 
definierten Mustern, Suchf unktionen, Definition von 
Ergebnismengen basierend auf SQL- oder PLSQL-Abf ragesprache, 
weitere Verfeinerung von Ergebnismengen mit PL/SQL, Sortierung 
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und Gruppierung von Ergebnismengen mit Standard-SQL, Export- 
und Dumpmoglichkeit der Oracle-Datenbank, so dass die Daten 
fur die Weiterverarbeitung in das Billing-System iibergeben 
werden konnen . Die folgenden Bearbeitungsf unktionen stehen 

*5 dabei zur • Verf iigung : Bearbeitung der Ergebnismenge mit 
Standard SQL/.PLSQL'-Update-Anweisungen, Bearbeitung der 
Ergebnismenge mit PL/SQLDatenbank-Prozeduren, Zuordnung einer 
Korrekturnummer zu einer Ergebnismenge (Revision Control 
Mode) , Bearbeitung der Ergebnismenge mit PL/SQL-Datenbank- 

10 Prozeduren innerhalb der Benutzeroberf lache, Freigabe oder 
Rucknahme einer Korrektur, Anderungsprotokollierung, 

• Protokollierung von WER macht WANN, WAS und WIE und der 
Ausgaben mit Zuordnung zu den Korrekturnummern, 
Ausgabefunktionen, Zuordnung von Dateinamen zu den Ausgaben, 
15 Vermerk des korrekten Endes einer Ausgabe, Ausgabemoglichkeit 
der korrigierten CDRs und optional der ursprunglichen CDRs 
oder kompletter Eingabef iles, Erzeugung des zum Eingabef ormat 
identischen Ausgabef ormats mit den vorhandenen 

Strukturdef initionen, Auflistung der ins System geladenen CDR- 
20 Dateien. Zur vereinf achten Bearbeitung steht eine 

Benutzeroberf lache zur Verfiigung, die intuitiv zu bedienen 
ist. Es wird darauf hingewiesen, dass das System auch aus 

©Unterkombinationen der o. g. Funktionen bestehen kann. 
1 
Im Folgenden wird die Erfindung anhand von 

25 Ausfiihrungsbeispielen naher erlautert, die in den Figuren 
schematisch dargestellt sind. Gleiche Bezugszif f ern in den 
einzelnen Figuren bezeichnen dabei gleiche Elemente . Im 
Einzelnen zeigt: 

30 Fig. 1 den strukturierten Aufbau der vorliegenden Erfindung. 
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Die zu analysierenden CDR-Tagesproduktionen-Daten liegen in 
einem Arbeitsverzeichnis in Dateiform vor. Anhand des 
Dateinamens Oder durch Benutzerangabe werden das Recordf ormat 
und die Formatversion der CDRs bestimmt. Innerhalb einer Datei 
*5 diirfen nur CDRs eines Recordf ormates in einer Version 

enthalten sein. Welche CDR-Dateien zu laden sind, wird vom- " 
Benutzer festgelegt. 

Anhand des erkannten Recordf ormates werden mit Hilfe der 
Strukturdateien Datenbanktabellen angelegt. Die Daten konnen 
10 dann mit dem f ormatabhangigem Decoder (GSM, TAP3, Mediation, 

• u. a.) decodiert und in die Datenbank geladen werden. 
Sowohl die Funktionsweise der Decoder, Encoder als auch die 
automatisierte Abbildung der Datenbeschreibungssprache auf 
eine relationale Datenbank wird in der bevorzugten 
15 Ausfiihrungsform tiber die Strukturdatei bestimmt. 

Die Decoder haben in der bevorzugten Ausfiihrungsform Methoden, 
urn defekte Bereiche innerhalb von CDR-Dateien zu erkennen, 
wieder aufzusetzen, zu iiberspringen und Korrekturen 
vorzubereiten . Zusatzlich sind die Decoder mit Testf unktionen 
20 und Dumpmoglichkeiten ausgestattet . 

©Durch die Verwendung einer relationalen Datenbank stehen alle 
Moglichkeiten der SQL-Sprache, der PL/SQL-prozeduralen 
Datenbanksprache und Programme mit Dialog im Zeilenmodus zur 
Verfiigung. So konnen weiterhin 3rd-Party-Tools benutzt werden, 
25 urn auf die Tabellen zuzugreifen, zu suchen und Veranderungen 
vorzunehmen. 

Die in der bevorzugten Ausfiihrungsform vorliegende 
Benutzeroberf lache beinhaltet in ihrem Bearbeitungsteil 
Benutzerdialoge zum Suchen, Darstellen, Korrigieren und 
30 Protokollieren von Ergebnissen. Fur groJitmogliche Flexibilitat 
konnen in der Oberflache SQL-Anweisungen und PL/SQL- 
Datenbankprogramme definiert und fur spatere Wiederverwendung 
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abgespeichert werden . Zur Darstellung und Manipulation ist ein 
CDR-Editor integriert. Ist ein Fehler gefunden und die 
betroffenen Daten selektiert worden, so konnen diese innerhalb 
der Oberflache mit Massenupdatef unktionen korrigiert werden. 
5 Alle Anderungen werden persistent und tagesgenau protokolliert 
und stehen fur- Revisions zwecke zur Verfiigung, indem auf Kopien 
gearbeitet wird. Auch die Oberflache kann ihr Layout, wie 
z. B. die Anordnung der Fenster, speichern und wieder 
verwenden . 

10 Die CDR-Strukturdateien sind eine Abbildung der CDR- 

• Spezifikationen bzw. Grammatik. Alle Feldbeschreibungen und 
die zugehorigen Wertebereiche fur verschiedene Netzelemente 
sind in ihnen abgelegt. Sie werden direkt aus den 
Spezif ikationen der Netzwerkausriister erstellt. Zu einer 
15 Version eines Formats existiert immer nur eine Strukturdatei . 
Alle Module greifen auf diese eine Strukturdatei zur 
Forma tbeschreibung zu. Dies hat den Vorteil, dass man bei zu 
erwartenden Anderungen an CDR-Formaten von Netzwerkelementen 
diese nur einmalig an zentraler Stelle in die Strukturdateien 
20 einarbeiten braucht. Diese Anderungen stehen dann sofort alien 
Modulen zur Verfiigung. 

©Die CDR-Strukturen werden in der Datenbank auf Tabellen 
abgebildet . 

Es werden in der bevorzugten Ausfiihrungsf orm folgende Arten 
25 von Strukturdateien unterschieden : 

1. ASN. 1-Strukturdatei, die ASN.l codierte Datenformate 
beschreibt . 

2. Nicht-ASN . 1-Strukturdatei, die in einer erf indungsgemalien 
Datenbeschreibungssprache vorliegt und alle nicht ASN.l- 

30 Datenformate beschreibt. 
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Zum Verarbeiten dieser Formate sind zusatzlich die 
f ormatspezif ischen CDR-Decoder sowie CDR-Encoder notwendig. 
Die Strukturdateien konnen somit einer f ortdauernden Pflege 
und Erweiterung fur neue Netzwerkelemente und neue 
*5 Sof twareversionen unterliegen. 

Die CDR-Decoder konvertieren alle oftmals im binaren Format 
vorliegenden CDRs in ein Datenbank lesbares Format, 
vorzugsweise in das ASCII-Format, das so genannte FAF-Format. 
In diesem Format werden die Feldnamen, Datenstrukturen und 
10 Datentypen dargestellt. Die Decoder sind vorzugsweise 
Batchprogramme . Die zu dekodierenden Formate werden 
vorzugsweise automatisch xiber Namenskonventionen fur 
Eingabedateien bestimmt. Andere Analysen zur Bestimmung des 
Formates sind jedoch denkbar. Aus dem Dateinamen sollten der 
15 notwendige Netzelementtyp sowie die zugehorige Versionsnummer 
des Formates hervorgehen . Format und Version konnen jedoch 
auch abweichend von der Namenskonvention vorgegeben werden. 

Der CDR-Decoder-Output (FAF-Format) wird, vorzugsweise ohne 
Zwischenspeicherung, als direkter Input fur das 
20 Datenbankinterf ace verwendet. Dadurch wird das File-system der 
Rechner nur zum Lesen der Eingabedaten benotigt. Das 
.aufwendige Speichern von Zwischenergebnissen entfallt. 




Urn eine moglichst grofie Anzahl von CDRs aus Dateien mit 
defekten Bereichen zu extrahieren, beinhalten die Decoder 
25 Funktionen zum Wiederauf setzen wahrend des Lesens einer 

Eingabedatei . Es werden Pattern (Suchmuster) festgelegt, die 
den Anfang von neuen Records beschreiben. Mit diesen 
Informationen versuchen die Decoder defekte Bereiche mit 
minimalem Verlust zu iiberspringen . Die Anzahl der 
30 Auf setzversuche wird vorzugsweise in der 

Verwaltungsinf ormation zur CDR-Datei vermerkt . Je Format und 
Version ist ein Maximum von Auf setzversuchen definiert. Nach 
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Erreichen dieses Maximums wird das Decodieren der Eingabedatei 
abgebrochen . 

Zur manuellen Behandlung von f ehlerhaf ten Bereichen in CDR- 
Dateien sind Methoden in den Decodern enthalten, die 
5 fehlerhafte Bereiche von CDR-Dateien in unstrukturierter Form 
in die Datenbank schreiben . ' Durch Schneiden, d. h. durch 
Setzen von Anfangs- und Endmarken, werden korrupte Bereiche in 
den Eingabedaten gekennzeichnet . Die Benutzeroberf lache 
erlaubt, in einer bevorzugten Ausf iihrungsf orm einzelne Bytes 
10 in unstrukturierten Bereichen in hexadezimaler Notation zu 
verandern . 




CDRs, die geladen wurden, sind nur lesbar, um unabsichtliche 
Veranderungen ohne begonnene Korrektur zu vermeiden. 
Testfunktionen zur Prufung der inhaltlichen Integritat einer 
15 CDR-Datei konnen beim Import pro Format automatisch oder 
manuell ausgefuhrt werden. 

SQL-Abfragen beinhalten auch die Priifung auf den NULL-Wert 
oder den x Leer-Wert' , um f estzustellen, ob eine Spalte gefiillt 
ist. Um die Abf ragen noch weiter verfeinern zu konnen, sind 
20 SQL-, PL/SQL-Funktionen verfugbar, die in der WHERE-Klausel 
verwendet werden konnen. 

^^^Suchabf ragen werden iiber das CDR-Select-Kommando definiert und 
bauen hierarchisch aufeinander auf. Das bedeutet, dass jedes 
CDR-Select-Kommando auf einem anderen CDR-Select basiert und 

25 die Suchmenge iiber eine UND-Verkniipf ung immer weiter 

eingeschrankt wird. Jede so definierte Suchmenge erhalt 
vorzugsweise e'infcn eigenen Namen, welcher als Referenz fur 
weitere CDR-Selects benutzt werden kann. Die vollstandigen 
SQL-Queries werden vom System automatisch erzeugt. Die 

30 ursprunglich geladene Gesamtmenge erhalt den Namen Initial. 



So ist z.B. eine automatische Query ein Header Trailer Check 
und Update am Beispiel vom TAP3 -Standard. 
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Im Header Check wird beispielsweise fur folgende Ref erenzdaten 
die korrekte Verwendung innerhalb der Call Detail Records 
iiberpruf t . 



.5 1 . taxes 

2. discounts 

3 . exchange rates 

4. utc time offsets 
^^^5. rec entities 

10 6. vas 

7. message descriptions 

8. called number analysis 



Fiir diese Daten sind innerhalb des TAP 3 Formates 
15 Unterstrukturen definiert. D. h. im File sollen z. B. alle 

vorkommenden Taxes (Taxcodes, Taxrate, ...) definiert sein. 
^^^\Ennerhalb der eigentlichen CDRs sollen nur diese Taxes 
^^referenziert werden. 

Werden Taxes ref erenziert, die nicht definiert sind, wird ein 
20 Warning ausgegeben. Eine automatische Korrektur kann hier 

nicht stattfinden, da nicht entschieden werden kann, ob die 
Definition des Taxes fehlt, oder ob die Referenz im CDR 
fehlerhaft ist. Der PAT-Benutzer muss entweder die Tax in die 
Referenzstruktur hinzufiigen (CDR INSERT) oder den Taxcode des 
25 CDR andern (CDR UPDATE) . 

Der Trailer-Check uberpriift, ob die im Trailer hinterlegten 
Summen mit den tatsachlich summierten Werten der CDRs 
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ubereinstimmen. Ausnahme 1st der fruheste und spateste „call 
timestamp" . 



Folgende Werte werden kontrolliert . 
/5 1. earliest and latest call timestamp 

2 . total charges 

3. total taxes 

4. total discounts 

5 . call event detail counts 

10 Der Trailer wird nach jeder Anderung der CDRs (CDR INSERT, CDR 
UPDATE, CDR DELETE) und vor jedem export neu berechnet 

Weitere automatische Queries sind denkbar und individuell auf 
dem SQL-Standard zu definieren. 

Zur Sicherstellung der Konsistenz konnen Korrekturen 
15 vorzugsweise nur auf Ergebnismengen der Suche angewendet 
werden. Dazu ist es notwendig, eine Revision, d. h. eine 

©Kopie, zu eroffnen. Das Neuerstellen einer Revision bewirkt, 
dass die Ergebnismenge in einen temporaren, schreibbaren 
Datenbankbereich kopiert wird, in dem Anderungen mittels des 
20 CDR-Update-Koiranandos durchgefiihrt werden konnen. Durch diese 
Vorbereitung wird jeder veranderte CDR mit seiner CDR-ID 
innerhalb der Datenbank vermerkt . 

Da iiber die aus den ' Strukturdateien abgeleiteten 
Tabellendefinitionen alle Spalten optional sind, kann jede 
25 Spalte auf NOLL gesetzt werden. Zusatzlich besteht die 

Moglichkeit, Felder abhangig von deren Datentyp auf einen 
x Leer-Wert r zu setzen. 
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In der bevorzugten Ausf iihrungsf orm wird das Loschen von CDRs 
indirekt bereitgestellt . Jede Tabellendef inition wird um ein 
Loschkennzeichen erweitert. Eine UPDATE-Anweisung setzt dieses 
Kennzeichen fur zu loschende CDRs. 

5 CDR-Dateien, in denen CDRS geandert wurden, werden als 

geandert markiert . In Abhangigkeit der Form des Exports konnen 
z. B. nur geanderte* CDR-Dateien exportiert werden. 

Korrekturen finden vorzugsweise nur auf Ergebnismengen 
(Revisionen) statt, da sonst eine Wiederholbarkeit nicht mehr 
10 gegeben ist. Um Revisionssicherheit zu erlangen, werden 
deshalb Veranderungen, vorzugsweise iiber SQL-UPDATE- 
Anweisungen oder iiber PL/SQL-Programme manuell oder 
automatisch vorgenommen . PL/SQL-Programme ermoglichen, Werte 
zu speichern und Platzhalter in UPDATE-Anweisungen mit Werten 
15 zu besetzen, bevor die Anweisung ausgefiihrt wird. 

Korrekturen werden vorzugsweise nur in Verbiridung mit einef 
Korrekturnummer vorgenommen, die einer Ergebnismenge 
zugeordnet wird. Zusammen mit dieser Nummer werden die 
Korrekturanweisungen und alle weiteren Aktionen abgespeichert . 

20 Protokolliert wird ,wer', ,was', ,wann', ,warum' und eine 

Sununenstatistik. Jeder veranderte CDR wird mit Korrekturnummer 

^^and CDR-ID innerhalb der Datenbank protokolliert. Dieses ist 
vorteilhaft, um mehr f ache Korrekturen des gleichen CDRs 
feststellen zu konnen. Der Export von Korrekturen wird 

25 vorzugsweise von dieser Protokolltabelle beeinflusst. Eine 
Losung zum Duplikatsproblem ist in der Ausgabef unktion 
beschrieben . 

Korrekturen werden vorzugsweise mit einem Namen und einer 
Beschreibung versehen und konnen mit einer jeweils neuen 
30 Korrekturnummer aufgerufen und wiederholt werden. Zur 

Beschleunigung kann verringertes Logging gesetzt werden. Bei 
Wiederverwendung einer Korrektur werden die *was und warum' - • 
Felder der Protokollierung mit den letzten Werten vorbesetzt. 
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Die geanderten CDRs werden aus der Datenbank exportiert und 
mit den f ormatspezif ischen Encodern unter Verwendung der 
Strukturdef inition in das binare Zielformat konvertiert. Die 
so geanderten Daten sind fur weitere Verarbeitungsschritte in 
'5 vorgegebenen Zielverzeichnissen zusammen mit der 

Protokollierung abgelegt. Die 'Ausgabe selbst bietet einige ' 
Optionen, wie z. B. die Ausgabe der urspriinglichen CDRs. 

Logisch sind folgende Arten von Ausgaben zu unterscheiden . 

1 . Die Ausgabe beschrankt auf die korrigierten CDRs in eine 
10 neu erstellte Datei. 

^^^^2. Die Ausgabe beschrankt auf die korrigierten CDRs unter 
Beibehaltung der urspriinglichen Dateinamen und 

3. Die Ausgabe von kompletten Daten mit dem urspriinglichen 
Dateinamen, in die die geanderten und die nicht von den 
15 Anderungen betroffenen Daten in ihrer urspriinglichen 
Reihenfolge ausgegeben werden. 

Die erste und zweite Art wird verwendet, wenn nur Teile einer 
Datei mit Fehlern behaftet waren, die Datei an sich aber im 
Abrechnungs system verarbeitet wurde . Die dritte Art kann 

©verwendet werden, urn vom Abrechnungssystem als ganzes 
'abgewiesene CDR-Dateien neu zu verarbeiten. 
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Patentanspruche 

Verfahren zur Analyse und/oder Bearbeitung von einer 
Menge von Call Detail Records (CDRs) , 

- mit einem Initialisierungsschritt, bei dem aus 
einem ersten Speicherbereich Strukturinf ormationen 
der Call Detail Records geladen werden und anhand 
dieser eine relationale Datenbank aufgebaut wird, 
die bei hierarchischen Strukturinf ormationen 
mindestens aus zwei miteinander rekursiv in Relation 
stehenden Tabellen besteht, die die Hierarchie 
abbilden, 

- mit einem weiteren Schritt, bei dem aus einem 
zweiten Speicherbereich die vorzugsweise binar 
vorliegende Menge von Call Detail Records in ein 
lesbares Format der Datenbank umgewandelt wird, 
insbesondere in das ASCII-Format, 

- mit einem weiteren Schritt, bei dem die lesbaren 
Call Detail Records entsprechend der 
Strukturinformationen in die Datenbank geladen 
werden, die im Initialisierungsschritt erzeugt 
wurde, ' 

- mit einem weiteren Schritt, bei dem SQL-Queries 
und/oder Datenbankprozeduren verwendet werden, urn 
fehlerhafte Call Detail Records zu bestimmen, die 
geandert werden konnen, 

- mit einem weiteren Schritt, bei dem mit Hilfe der 
Strukturinformationen und dem Aufbau der Datenbank 
die Call Detail Records in einen dritten 
Speicherbereich zuruckgespeichert werden, der im 
Aufbau der ursprunglichen Menge an Call Detail 
Records entspricht . 
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2. Verfahren nach dem vorhergehenden Anspruch, dadurch 

gekennzeichnet, dass fur jeden Typ in der 
Strukturdef inition eine Tabelle angelegt wird. 

~5 3. Verfahren nach einem oder mehreren der 

vorhergehenden Anspruche, dadurch gekennzeichnet, 
dass bei der Auflosung von hierarchischen 
Datenstrukturen solange normalisiert wird, bis keine 
nicht beschrankte Widerholungsgruppe vorliegt, wobei 
10 im Falle von nicht beschrankten Wiederholungsgruppen 

rekursiv eine 1:N Relation zwischen einer neuen 
Tabelle aufgebaut wird, die wiederum normalisiert 
die Wiederholungsgruppe aufnimmt. 

15 4 . Verfahren nach einem oder mehreren der 

vorhergehenden Anspruche, dadurch gekennzeichnet, 
dass der Decoder zum Einlesen der Menge von Call 
Detail Records Binardaten nach Fehlern, insbesondere 
nach Protokollf ehlern, durchsucht, urn diese zu 

20 markieren, und urn ggf . den Einleseschritt neu 

anzusetzen . 

©5. Verfahren nach dem vorhergehenden Anspruch, dadurch 

gekennzeichnet, dass die fehlerhaften Bereiche in 
25 eine ausgewiesene Datenstruktur geschrieben werden. 

6. Verfahren nach einem oder mehreren der 

vorhergehenden Anspruche, dadurch gekennzeichnet:, 

dass benutzerspezif ische Erweiterungen, insbesondere 
30 SQL-Select-Statements, fiir die Suche von defekten 

Call Detail Records individuell abspeicherbar sind. 



35 



7. 



Verfahren nach einem oder mehreren der 
vorhergehenden Anspruche, dadurch gekennzeichnet, 
dass bei einer Anderung ein Duplikat des Call Detail 



SOFPT03173 



- 15 - 



06.10.03 



Records angelegt wird 
und/oder 

eine Protokollierung stattfindet, indem vorzugsweise 
der Bearbeiter und/oder der Zeitraum und/oder eine 
5 Protokollnummer vergeben wird, und/oder 

bei einer Loschung ein Loschkennzeichen vergeben-' 
wird* 

Verfahren nach einem oder mehreren der 
vorhergehenden Anspruche, dadurch gekennzeichnet , 
dass die Ausgabe durch einen Encoder erfolgt, der 
auf der Basis der Strukturinf ormationen und der 
Datenbank die Call Details Records im ursprunglichen 
Einlesef ormat ausgibt, das vorzugsweise binar ist. 

Verfahren nach einem oder mehreren der 
vorhergehenden Anspriiche, dadurch gekennzeichnet, 

dass die Eingabe und/oder Ausgabe in eine Datei 
erfolgt, die vorzugsweise im Binar format die Menge 
von Call Details Records speichert. 

Verfahren nach einem oder mehreren der 
vorhergehenden Anspruche, dadurch gekennzeichnet, 

dass automatische Korrekturen bei dem Vorliegen 
bestimmbarer Mustern durchgefiihrt werden. 

11. Verfahren nach einem oder mehreren der 

vorhergehenden Anspruche, dadurch gekennzeichnet, 
dass eine Anderung der Strukturdatei sich auf den 
30 Aufbau der Datenbanktabellen und/oder auf die 

Funktion des Encoders und/oder auf die Funktion des 
Decoders auswirken . 





12. Verfahren nach einem oder mehreren der 
35 vorhergehenden Anspruche, dadurch gekennzeichnet, 
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dass die Datenbank dynamisch bei jedem erneuten 
Einlesen einer Datei erzeugt wird oder einmalig fur 
jeden Strukturtyp, der durch eine 
Strukturinformation bestimmt ist. 

13. Verfahren nach einem oder mehreren der 
vorhergehenden Anspriiche, dadurch gekennzeichnet, 
dass Views in Abhangigkeit der Strukturinf ormationen 
fiir eine Datenbank generiert werden . 

14. Software fiir einen Computer, dadurch gekennzeichnet, 

dass ein Verfahren nach einem oder mehreren der 
vorhergehenden Anspriiche fiir einen Computer 
implementiert ist. 

15. Datentrager fiir einen Computer, gekennzeichnet durch 

die Speicherung einer Software nach dem 
vorhergehenden Sof twareanspruch. 

16. Computersystem, gekennzeichnet durch eine 
Einrichtung, die den Ablauf eines Verfahrens nach 
einem oder mehreren der vorhergehenden 

Verf ahrensanspriiche erlaubt . 
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